With the fast growing popularity of mobile devices, such as Palm Pilots, mobile telephones, pagers and mobile computers, there is also a fast growing demand for application programs for mobile devices. However, developing software components for mobile devices is a difficult task because mobile devices operate under several constraints which are distinct from those imposed on corresponding non-mobile components.
First, mobile devices generally operate using rechargeable or replaceable batteries that are small and light, thus have low power capacity. Low power capacity limits the types of CPU's that can be used on a mobile device, as well as the manner in which the CPU performs its task. For example, a handheld computer employs a slower CPU using less power than a CPU in a corresponding desktop computer. In addition, the CPU in a handheld computer spends much time in a low power “doze” mode. Low power capacity also limits the types and the amount of storage devices used in mobile devices. For example, a handheld computer often employs power-efficient memory technologies, such as flash, and includes a significantly lower amount of memory components than those available for a corresponding a desktop computer. As another example, most of the mobile devices lack the memory management unit (“MMU”) that efficiently handles the use of RAM during the run time and enables the passing of global variables. The lack of the MMU on a mobile device severely limits flexibility of the programming environments for software developers.
Second, mobile devices are generally constrained by limitations on their price ranges. The market dictates that the price of a handheld computer be significantly lower than that of a corresponding desktop computer. The price limitation implies that a handheld computer is built using components from older technologies vis-à-vis a corresponding desktop computer. In general, mobile devices are slower than their corresponding desktop devices.
A third constraint is that mobile devices require mobile solutions to a new set of problems. A wide variety of mobile hardware solutions, such as barcode scanners, mobile modems and global positioning modules, are available in the market. The mobile hardware solutions require significant efforts from software developers to integrate them with software solutions that would present to the end-customers easy and friendly user-interfaces. In addition, providers of hardware solutions are challenged to provide reasonable hardware-to-software interface mechanisms.
These constraints have resulted in providing static and non-expandable programming environments for mobile devices. The programming environments for mobile devices also lack a built-in central services interface to handle the integration of software components in an application program. Thus, the creation of component-oriented software is rendered difficult and becomes a custom solution. Accordingly, prior art programming environments for mobile devices present a substantial obstacle to software developers for mobile devices. Adding functionality to the operating system of a mobile device is difficult. Adding the same functionality to a mobile device having a different operating system requires in general not only a different set of function calls and programming methods, but a different programming environment altogether. Furthermore, conventional embedded software programming environments do not support global variables, thereby presenting severely limited programming environments to software developers.
Component software such as the Component Object Model (“COM”) created by Microsoft Corp. for its Windows operating system provides an extremely productive way to design, build, sell, use and reuse software. COM is fully described in “The Component Object Model Specification,” available from Microsoft Corp., Document No. LN24772-91 (1991) incorporated herein in its entirety by reference. COM provides the following services:                a generic set of facilities for finding and using services providers (whether provided by the operating system or by applications, or a combination of both), for negotiating capabilities with service providers, and for extending and evolving service providers in a fashion that does not inadvertently break the consumers of earlier versions of those services;        use of object-oriented concepts in system and application service architectures to manage increasing software complexity through increased modularity, re-use existing solutions, and facilitate new designs of more self-sufficient software components; and        a single system image to users and applications to permit use of services regardless of location, machine architecture, or implementation environment.        
COM when implemented can work only within the Microsoft Windows operating system. Thus, COM does not work across varied platforms. In addition, COM requires elaborate supporting files and a system wide registry procedure. Given the premium placed on the CPU power and storage space of a mobile device, COM does not present a viable solution for mobile devices. Furthermore, in COM, functional objects are called using dynamic link library (“DLL”) files, and the calling procedure requires an explicit registry procedure. The modular scalability of COM is limited by the use of DLL files which are not programmable files and are not themselves callable objects. COM is not designed for mobile devices which must operate under restricted power and storage capability.
Examples of prior art methods providing platform independence include the CORBA architecture and Sun Microsystems' Java. A CORBA architecture employs a middle layer called Object Request Broker (“ORB”) to facilitate integration of software objects. The middle layer requires memory and a CPU's processing power. CORBA is not a viable or desirable option for a mobile device.
A Java architecture employs a virtual machine which provides platform independence at run-time. A virtual machine facilitates different object components to find each other, and the object components interact with each other via the virtual machine. Because object components interact via the virtual machine, the processing speed is noticeably slowed down in a Java architecture. In addition, the virtual machine requires a large amount of memory. Furthermore, a software developer is required to use the Java language, and thus needs to expend a large amount of time and effort to become versatile in using a Java system. In addition, a large amount of legacy codes written in non-Java language becomes unavailable in a Java architecture. The Java architecture is not a or desirable option for a mobile device.
Prior art programming methods for mobile devices are inadequate. There is a need to provide flexible and platform independent programming environments for mobile devices, especially given the growing demand for and use of mobile devices.